The scenario where a terminal (UE/MS) can get access via a number of different access technologies is becoming more and more common. For example, mobile phones often come equipped with both cellular and WLAN (Wireless Local Area Network) access capabilities. Laptops often have Ethernet, WLAN and sometimes also cellular access capabilities. These different interfaces may be used one at a time or they may be activated simultaneously. However, more importantly, in the current solution a given service or a given IP session is typically only using one access at a time.
Currently 3GPP EPS—Evolved Packet System (also known as 3GPP SAE—System Architecture Evolution) is defining solutions for how session continuity can be achieved when a UE (User Equipment) moves between different accesses. This can e.g. mean that a service that is running over a cellular access is moved to run over a WLAN access instead. But also with this solution, the UE is only using one access at a time and during an access change, the whole IP session and all running services within that IP session is moved from source access to target access. Simultaneous use of multiple accesses (a.k.a. multi-homing) is not supported, except for very short times during a handover between two accesses.
There is work ongoing in IETF (Internet Engineering Task Force), and related work being started up in 3GPP, for defining mobility solutions in multi-homing scenarios. As part of this work the concept of “flow mobility” is investigated, i.e. only a subset of the IP flows for a given IP session is moved from one access to another. For example, it could be that only the video component of a multimedia call is moved from cellular access to WLAN, while the IP flows related to the voice component of the same call stays in cellular access. One IP session would thus be active over multiple accesses simultaneously.
One solution proposed in 3GPP work on simultaneous multi-access (called MAPIM—Multi Access PDN connectivity and IP flow Mobility—in 3GPP) is that it is the UE that is controlling the flow mobility. This means that the UE activates each access (e.g. 3GPP access and WLAN) and decides which IP flows are transported over each access. The UE also selects a default access out of the available accesses. IP flows that have not been explicitly assigned a specific access are carried over the default access. The network may choose to accept a reject a request from the UE, but not initiate a handover procedure.
This UE-centric control of IP-flow mobility is a key principle of the solution and is in fact an extension of the inter-access mobility defined for 3GPP SAE in release 8. In release 8 it is always the UE that triggers a handover between two different accesses. One reason for this is that the UE is the only entity in the network aware of e.g. signal quality of different accesses technologies. Also, a UE-triggered handover procedure avoids the need for interactions between heterogeneous access networks. Network-triggered handover procedures, i.e. procedures where the network initiates the handover, are only defined between certain “tightly coupled” accesses such as GERAN (GSM Edge Radio Access Network), UTRAN (UMTS Terrestial Radio Access Network) and E-UTRAN (Evolved UTRAN).
The UE may use multiple criteria for choosing which access that shall carry certain IP flows. First of all the UE has access selection policies (either pre-configured in the UE or received over-the-air from the network operator). The policies may contain a prioritized list of accesses to be uses for certain services. Then the UE also has information about the signal quality, characteristics, throughput etc of the different available accesses.
One problem occurs when the UE-centric mobility paradigm for IP flow mobility is combined with network-initiated QoS procedures. When only a single access is active (as in release 8) there is no issue since the network has no choice when establishing new QoS resources using the network initiated procedures. However, when multiple accesses are available simultaneously, the network in principle has a choice between the different access technologies. According to the UE-centric mobility paradigm, it is however always the UE that decides which access to use for a certain IP flow. The current solution in the UE-centric mobility paradigm is that network sets up network-initiated QoS resources for new IP flows on the default access. It is then up to the UE if it wants to trigger a mobility procedure afterwards to move the new IP flow to another access.
There are several drawbacks with this approach. First of all it results in an inefficient service establishment procedure for services that use network-initiated QoS (Quality of Service) procedures. The network must always establish the QoS resources in the default access first and then the UE can move the resources to a more suitable access later (e.g. based on the access selection policies). The move of an IP flow for a service requires the NW to establish the corresponding resources in the new access and tear down the resources in the old access.
Furthermore, it may also result in a non-optimal service experience since the service may be initiated in a non-optimal access before it can be moved (by the UE) to a more optimal access with e.g. higher bit rate capacity and/or better QoS capabilities. The current state of the art is illustrated in FIG. 2. The figure will not be described in detail in the present patent application. More information about this signaling flow procedure can be found in 3GPP technical specifications TS 23.401, TS 23.402, TS 23.203 and TS 23.261.
One solution to this problem could be that the network initiates the QoS procedures in the “best” access directly, instead of in the default access. This however breaks the UE-centric mobility paradigm. Another problem is that the network nodes initiating the QoS procedures do not have access to the access selection policies since such policies are stored in the Access Network Discovery and Selection Function (ANDSF). The network nodes therefore do not know which access is the “best” access. A third drawback is that network-based access selection and network-triggered inter-access handover makes the heterogeneous accesses more tightly coupled. Coupling heterogeneous accesses is non-trivial since each access typically has different solutions to key aspects such as security, mobility, etc.